This whole bit here is equivilent to: isRepresentableByInt64

This here doesn't really seem right. We're just erasing blindly in the middle, despite not knowing that we have enough room. I think what we REALLY want is to decide to keep the first N characters, and the last N characters (and still do the ...).

Additionally, I think instead of doing the whole to-string mechanism here (and since we're doing it in hex it is easy to do so), we could just do a numeric-trim of hte front/back instead and join them afterwards.

THAT SAID: I'm not sold on doing this as a hex-print, I think we can keep it decimal. We could have a new function in APInt that does a print only the first N and last N, with dots between kind of thing. If we have that, we don't actually have to do any branching here, because choosing a reasonable number there plus decent algorithm for it (basically, normal RHS processing until we reach 'N' digits, then figure out how many orders of magnitude to divide by using 'log' to figure out how to get the remaining 'N').

I like the idea of keeping the decimals. I think it avoids the weirdness happening in the enum test, which I think might have been caused by some characters getting cut in half. Working on it

Hi just wanted to run something by you before I make further changes.
Before, we were using the value of the APInt to decide if we would truncate or not. I am tempted since we will be looking at the number of digits anyway to decide how many to skip to instead use that as the deciding factor, so something like, if the number of digits in the APInt value is larger than 40 (This is if we want to keep N=20) then we truncate keeping the first and last 20.
Were you thinking of some other way to decide what N should be by the way?

I don't really know how this is supposed to work. We need to know what to display without printing the value to a string at all, because THAT is what's breaking our neck. The simplest solution would be to just check the value (or even getActiveBits()?) and if that is larger than some arbitrary value (you can just check that printing the note doesn't take longer than, say, 3 seconds), we simply skip the note altogether.

Hi just wanted to run something by you before I make further changes. Before, we were using the value of the APInt to decide if we would truncate or not. I am tempted since we will be looking at the number of digits anyway to decide how many to skip to instead use that as the deciding factor, so something like, if the number of digits in the APInt value is larger than 40 (This is if we want to keep N=20) then we truncate keeping the first and last 20. Were you thinking of some other way to decide what N should be by the way?

I had no problem with the "around 20 digits" on each side. My suggestion was to have the actual printing in APInt do the magic (via separate function). So algorithmically, it is something like:

unsigned end_digits_printed = 0;
// Print the 'end digits'.
while(value != 0 && end_digits_printed <20) {
  APInt temp;
  int64_t rem;
  APInt::udivrem(value, 10, temp, rem);//udiv becasue before this we figured out 'negative' and made it positive.
 
  //add-rem-to-buffer
  value = temp;
}
// print the '...'
if (value == 0) return;

// This gives more of a log-base-16 by dividing it by 4 I think (or should this be a multiply?), but gives us an approximation.
unsigned ApproxDigitsLeft = value.logBase2() / 4;

if (ApproxDigitsLeft > 20)
  value = value.udiv( 10 * (ApproxDigitsLeft - 20)); // removes the 'middle' approx all-but-20.


// print the leading part.
while (value != 0) {
   // same stuff as above.
}

So basically, we don't have to calculate the whole thing to figure out how many to remove, but we can be 'reasonably accurate' here. WDYT? ALSO, the base-16 to base-10 approximation might need some tweeking so that we always print some of the leading digits (though I think 'at least 20 hex digits' is... a lot to make sure of that.). We MIGHT want to make the top-half a little smaller since there is a hex->decimal relationship, so maybe make sure we're printing the top 16 hex-digit-worth?

Cool, that is basically what I had in mind. I'm extending toString and there is a Pos variable as you have there counting how many digits were already inserted and we can get the number of remaing using value.logBase2/log2(Radix) +1 that actually gives the exact count. Then the division will be value.udiv( Radix ^ (ApproxDigitsLeft - 20)). I just need to get that pow working it's throwing a seg fault but I'll figure that out.

@tbaederr I think the last comment from @erichkeane probably made it clearer but basically what we were discussing is creating a separate version of toString (tentatively naming it toStringTruncated) that does not print all of the number, the implementation of that function basically takes the number and does a huge number of divisions to get each digit in the resulting String, the approach suggested is that once we have printed 20 digits we do a division that jumps us to the first 20. I'm hoping I can have something to push in the next couple days time permitting.

we can get the number of remaing using value.logBase2/log2(Radix) +1 that actually gives the exact count.

That sounds VAGUELY familiar :) Its been a few decades since I've been in a math class....

With the 'pow', you probably need SOME sort of guard to make sure you don't exceed the number we can store.

This seems VERY wrong here...

Are we still using hex?

Don't do a newline here I think? If you do it separates the things during rendering.

What is making these print in hex?

This test was not fixed yet I was hitting a problem where the division was throwing a Floting point error that I was still looking at.

Should this be an argument?

IS there ANY perf hit whatsoever for doing this? We're doing quite a bit of work on what is perhaps a hot-ish path, can you run the compiler perf tester thing on this? @Endilll knows how if you don't.

I've never run them. @Endhill if you could give me some pointers, appreciate it.

See "Pre-Commit Measurements" section at https://llvm-compile-time-tracker.com/about.php

ALSO: Why cast to int32, but then assign to an unsigned? Should we be doing math as unsigned? or as signed?

Also, a comment on what this is doing could be helpful.

Also... is there value to pre-calculating log2(Radix) and keeping it somewhere so we don't re-evaluate it every time? or is log2 pure?

Would there be any way to find the 'first' digit or something in this case? I find myself wondering if there is a 'better' way here...

IS there any special-casing we can do here for base-10? I DO find myself wondering if pow is the best way for Radix==10. I know that V<<3 + v << 1 is the same as *10, I wonder if someone better at math than I could come up with a way to apply that as a way to do the 10^N as a simple set of shifts/math?

I was not 100% happy with that else either so I have been thinking about this.

I could not find any way to do it with just shifts also because if we want to support what toString supports, which I think makes sense, the else branch which does divisions instead of shift is for base 10 and base 36.

I had one alternative idea but I was still checking to see if it would work, the property I am trying to check is that if we take a word worth of bites in one of these multiword APInt we can work with it in isolation I mean that there is no digit that is half in one word half in the other.

The idea was that instead of looking at the number of digits already printed we could take a word worth of bites and use the usual approach that uses division to get some number of digit one by one. After that if we were truncating we would shift log2(getActiveWords-2*wordlenght) (might be -1 at that point rather than -2 actually). The idea is this should put us at the first active word, there we would continue using divisions to get the digits. This would give with the default word size some 9/10 digits from the end, and some arbitrary number from the beginning but at most again 9/10. Does it sound like this could work?

I think that sounds like it could work? I'm not sure of the size implications...

One thing to note, 'exactly 20' numbers in the 1st number isn't important. What IS important is 'enough of the first few that a couple of patterns are obvious', so the numbers have to be accurate, but the number OF them isn't important.

I'm not sure I have a better idea, but I'm still thinking :) Have an attempt at the above and see if it works out.